home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 659 < prev    next >
Text File  |  1994-08-27  |  3KB  |  70 lines
  1. Subject: repl
  2. Date: Fri, 01 Jul 1994 11:13:04 +1000
  3. From: Warwick Allison <warwick@cs.uq.oz.au>
  4. Precedence: bulk
  5.  
  6.  
  7. Annius Groenink:
  8. >Leaving the right mouse button free is not necessary as MTOS and WINX
  9. >allow using the left mouse button in background windows.
  10.  
  11. Normal TOS does too.  NOWHERE does GEM insist that you treat a TOPPED
  12. message as something that MUST top your window.  Events in GEM are
  13. advisory only.  When GEM++ receives a TOPPED message, it uses the mouse
  14. coordinates of the message as a click.  If the click is not on anything
  15. interesting, it just does a TOP, otherwise, it leaves the window untopped
  16. and performs the operation.  Any program that has a Toolbox and a Document
  17. Window appreciates this behaviour.  PageStream and Calamus do it, of course,
  18. and I noticed that the new version of Kandinsky does also.
  19.  
  20. I'm amazed how few programs use this feature.  GEM++ adopts the attitude
  21. that ANYTHING can happen on backgrounded windows.  It takes great care to
  22. do efficient object scrolling, even if that object is partially obscured.
  23.  
  24. The top-window-is-active model is tiresome.  We have to put up with it for
  25. keyboard in most cases (although GEM++ gets around this by allowing
  26. click-to-type on backgrounded editable text fields).
  27.  
  28.  
  29. Craig.Graham@newcastle.ac.uk wrote:
  30.  
  31. >A shame GEM
  32. >only provides two rectangle events - a rectangle list for event_multi()
  33. >would solve this problem
  34.  
  35. Unfortunately, it wouldn't.  What rectangles would you use?  One for
  36. every object?  That's too inefficient.  objc_find() uses the
  37. hierarchical structure of objects to provide for VERY efficient
  38. rectangle tracking.  event_multi() would have to take a list of FORMS
  39. to be efficient.  This is also how it would be provided by a library. 
  40. I just don't see it as warranted, since not all s/w will implement
  41. object tracking, and hence the GUI would be more inconsistent.  
  42.  
  43. If this list considers rectangle/object tracking should be part of the
  44. standard, then I'll gladly follow it (since many progs would then have
  45. this consistent tracking feature).  But it would have to be implemented
  46. correctly (ie. not busy wait), and as one of the major ST softwares,
  47. Calamus, doesn't bother to do it correctly (they use busy-wait), I
  48. don't see much hope for it. [This is no comment against Calamus.  They
  49. could have just not given use all the neat features provided by
  50. rectangle tracking, such as short-cut identification, continuous help,
  51. cursor change in windows, etc. - I'd rather have those features in a
  52. large product like Calamus, even if it does cost mtasking] 
  53.  
  54.  
  55. >I personally never use form_button or form_keybd at all........you can
  56. >get along quite easily without them - check out the fully non-modal GUI
  57. >in CLA for an example of this.
  58.  
  59. Indeed, the more specialized a library is, the less likely it is to call
  60. these.  For form_keybd, the default keyboard handling is terrible, so
  61. often replaced.  Neither do clipping either.  If LTMF-2 can provide this
  62. advanced keyboard handling, I'll gladly leave it out of GEM++.
  63.  
  64.  
  65. >Take the argument to private email ...
  66. Apologies.
  67.  
  68. --
  69. Warwick
  70.